Four Types of Shift Left Testing

The Consequences of Testing Late in the Lifecycle

For decades, it has been well known that defects are more difficult and expensive to fix the later they are found in the lifecycle. This phenomena is one reason why treating testing as a sequential phase at the end of waterfall development has long been viewed as a major pitfall of system and software testing. Examples of the harm caused by postponing testing include

Testers may be less involved in initial planning, often resulting in insufficient resources being allocated to testing.

Many requirements, architecture, and design defects are not uncovered and fixed until after significant effort has been wasted on their implementation.

Debugging (including identifying, localizing, fixing, and regression testing defects) becomes harder as more software is produced and integrated.

Encapsulation makes it harder to perform whitebox testing and to achieve high levels of code coverage during testing.

There is less time to fix defects found by testing, thereby increasing the likelihood that they will be postponed until later increments or versions of the system, which creates a "bow wave" of technical debt that can sink projects if it grows too large.

These negative consequences of late testing increase development and maintenance costs, lead to missed deadlines and schedule delays, decrease quality due to residual defects, and generally lower project morale and job satisfaction.

---

ライフサイクルの後半におけるテストの結果

何十年もの間、不具合はライフサイクルの後半に発見されればされるほど、修正するのが難しくなり、費用もかかることがよく知られてきた。この現象は、テストをウォーターフォール型開発の最後の逐次フェーズとして扱うことが、システムテストやソフトウェアテストの大きな落とし穴であると長い間考えられてきた理由の一つである。テストの先送りがもたらす弊害の例には、次のようなものがある。

テスト担当者が初期計画にあまり関与しなくなる可能性があり、その結果、テストに割り当てられるリソースが不十分になることが多い。

要求事項、アーキテクチャ、設計の欠陥の多くは、実装に多大な労力が費やされた後でないと発見されず、修正されない。

デバッグ（欠陥の特定、ローカライズ、修正、リグレッションテストを含む）は、ソフトウエアの生産と統合が進むにつれて難しくなる。

カプセル化によって、ホワイトボックステストの実施や、テスト中の高レベルのコードカバレッジの達成が難しくなる。

テストによって発見された不具合を修正する時間が少なくなり、その結果、不具合がシステムの後続のインクリメントやバージョンまで先送りされる可能性が高くなる。

テストが遅れることによるこのような悪影響は、開発コストやメンテナンスコストを増加させ、納期遅れやスケジュール遅延を引き起こし、欠陥が残ることによる品質の低下を招き、一般的にプロジェクトの士気や仕事の満足度を低下させる。

Because the term testing means different things to different people, we need to ensure a common understanding of the word before discussing the four different types of shift left testing. Traditionally, people have decomposed verification into four different methods: analysis, demonstration, inspection, and testing. For many people, however, testing has become synonymous with quality assurance and the word has been expanded to include all four verification methods. Here and in my book, Common System and Software Testing Pitfalls: How to Prevent and Mitigate Them: Descriptions, Symptoms, Consequences, Causes, and Recommendations, I restrict the term testing to its traditional meaning:

---

テストという言葉の意味は人によって異なるため、4つの異なるタイプのシフトレフト・テストについて議論する前に、この言葉の共通理解を確認する必要がある。伝統的に、人々は検証を4つの異なる方法、すなわち分析、実証、検査、テストに分解してきた。しかし、多くの人々にとって、テストは品質保証と同義語となり、この言葉は4つすべての検証方法を含むように拡大されてきた。ここと拙著『よくあるシステムテストとソフトウェアテストの落とし穴：どのように防ぎ、軽減するか：Descriptions, Symptoms, Consequences, Causes, and Recommendations）では、テストという用語を従来の意味に限定している：

The V-model has come under a great deal of significant - and justified - criticism in recent decades because it can easily be interpreted to imply a strict sequential waterfall development cycle that is inconsistent with a modern evolutionary (that is, incremental, iterative, concurrent, and time-boxed) development in projects that use Agile or DevOps approaches. The V model can also be interpreted as prohibiting a test-first approach or test-driven design (TDD). On the other hand, as long as system and software engineers remember its limitations and view it merely as notional and only showing logical relationships between development activities, the V model provides a succinct way to illustrate our descriptions of approaches to shift left testing. With this in mind, shift left essentially means moving testing to the left on the V.

---

Vモデルは、アジャイルやDevOpsアプローチを使用するプロジェクトにおける最新の進化型（つまり、インクリメンタル、反復的、並行的、タイムボックス型）開発と矛盾する、厳格なウォーターフォール型の逐次開発サイクルを暗示していると容易に解釈できるため、ここ数十年、非常に多くの（そして正当な）批判にさらされてきた。V字モデルは、テストファーストアプローチやテスト駆動設計（TDD）を禁止しているとも解釈できる。その一方で、システムエンジニアやソフトウェアエンジニアがその限界を忘れず、V モデルを単に概念的なものとして捉え、開発活動間の論理的な関係を示しているに過ぎないと考える限り、V モデルは、シフトレフトテストのアプローチの説明を簡潔に示す方法を提供する。このことを念頭に置いて、左シフトとは、本質的に、テストをV字の左側に移動させることを意味する。

There are four basic ways to shift testing earlier in the lifecycle (that is, leftward on the V model). These can be referred to as traditional shift left testing, incremental shift left testing, Agile/DevOps shift left testing, and model-based shift left testing.

---

ライフサイクルの早い段階（つまり、V字モデルの左方向）でテストをシフトさせるには、4つの基本的な方法がある。これらは、伝統的な左シフトテスト、インクリメンタル左シフトテスト、アジャイル/DevOps左シフトテスト、モデルベースの左シフトテストと呼ぶことができる。

As shown in Figure 5 below, model testing moves testing to the left side of the Vs by testing executable requirements, architecture, and design models. This shift enables testing to begin almost immediately, instead of waiting a long time (traditional), medium time (incremental), or a short time (Agile/DevOps) until software on the right side of the Vs is available to test. This trend is just beginning and will become increasingly popular as executable models and associated simulation/testing tools become more widely available.

下の図 5 に示すように、モデルテストは、実行可能な要件、アーキテクチャ、および設計モデルをテストすることで、Vs の左側にテストを移行する。このシフトにより、Vsの右側のソフトウェアがテスト可能になるまで、長い時間（従来型）、中程度の時間（インクリメンタル）、または短い時間（アジャイル/DevOps）を待つ代わりに、ほぼ即座にテストを開始することができます。このトレンドは始まったばかりであり、実行可能なモデルや関連するシミュレーション/テストツールがより広く利用できるようになるにつれて、ますます普及していくだろう。

https://gyazo.com/a3465d0ab10e2bc408bf91e7f4f64b0b